The associated arch8259d.psbin includes change pages for the following
three items:
 
(Item 8259) Further clarify DLUR processing of short RSP(BIND) RUs
------------------------------------------------------------------
Review of AMB item 8218 discovered a problem in the description of
setting the RSP(BIND) pacing fields when constructing a short RSP(BIND).
The pacing fields are supposed to be set for the REX (SLU) stage, but
the current description details the process for setting the APPN (PLU)
stage.
 
The proposed solution is to replace the DLUR architecture reference
section on setting the pacing fields in "short RSP(BIND) processing"
with the following:
 
    - setting the pacing fields in the RSP(BIND) for the REX stage
      to the BIND request values
 
Subsequent processing (actually the section that's currently in the
document about setting the pacing values for the PLU stage) would take
the REX stage values and change them to the PLU stage values.
 
(Item 8260) Add DLUR processing of Whole BIUs Required Indicator (WBRI)
-----------------------------------------------------------------------
Christine Martin of Data Connection Ltd. asked whether the WBRI setting
in an extended short RSP(BIND) should not reflect the segment
reassembly support of the DLUR.
 
The problem statement is as follows:
 
   I've got a quick question about the recent clarification to the DLUR
   architecture for extending short positive response BINDs.  The
   clarification states that converting the short +RSP(BIND) into an
   extended short form RSP(BIND) includes:
 
      - setting the whole-BIUs required indicator on if the RSP(BIND)
        will be reextended.
 
   From looking at formats, setting this bit on (1) means that the
   sending node doesn't support receipt of segments on this session.
   Shouldn't this be set off (0) indicating that the sending node
   supports receipt of segments on this session?  (I notice that the
   formats state that the bit is reserved for non-extended, non-LU 6.2
   BINDs - so again, wouldn't it be set to 0?)
 
The current description was derived from the NCP BF implementation.  It
turns out that NCP always sets WBRI on because NCP never reassembles
segments at its BF.  However, a DLUR BF should have as an implementation
option segment reassembly support and should then set the WBRI
according to its own segment reassembly capabilities.  This could be
done both on RSP(BIND)s built by the DLUR as well as received by the
DLUR.
 
What needs clarification in DLUR architecture is how to set WBRI
based on DLUR's capabilities.
 
The proposed solution is to replace the WBRI section in "short RSP(BIND)
processing" in the DLUR architecture reference with a new section on
"WBRI processing" within the RSP(BIND) section; it would include the
following:
 
   * WBRI processing - a DLUR can, as an implementation option, support
     segment reassembly at its BF; whether or not a DLUR provides this
     support is reflected in how it sets the Whole BIUs Required
     Indicator (WBRI) - WBRI=0 means sending node supports receipt of
     segments on this session while WBRI=1 means sending node does not
     support receipt of segments (this processing could apply to
     RSP(BIND)s built as well as received by the DLUR):
 
       - if WBRI is valid (not a reserved field), use the received value
       - if WBRI is reserved, act as if DLUR received WBRI=1
       - if WBRI=1 and DLUR BF can support segment reassembly, set
         WBRI to 0
       - if WBRI=1 and DLUR BF can't support segment reassembly, set
         WBRI to 1;
 
(Item 8261) Clarify DLUR processing of extended UNBIND RUs
----------------------------------------------------------
DLUR testing uncovered a condition not described in the architecture,
specifically how the DLUR BF should process extended UNBIND RUs when
the dependent LU can only handle unextended UNBINDs.
 
The problem statement is as follows:
 
    I've run across a problem with "extended" UNBINDS.
    When we receive a Bind for a DLuR LU we unextend it,
    send it to the LU, then extend the ensuing +rsp(Bind).
    Since we've accepted an extended Bind, Vtam will send an
    "extended" Unbind.  Currently, there is no code to
    unextend Unbinds and so the Unbind is sent as is to the LU.
    The LU however is ( for some reason ) checking the length of
    the RU, and since it never expects Unbinds longer than 6 bytes,
    it rejects the RU and brings down the session.  In most cases
    we're taking down the session anyway, but not in the case of a
    NetView logon. NetView sends an "UNbind with a bind forthcoming
    type of Unbind.  Since the LU is bringing down the session, the
    "forthcoming Bind" is also rejected.
    So, do we need to add code in the DLuR to "unextend" Unbinds??
    or Is this a bug in the LU code for not accepting the Unbind
    and just ignoring the extra data (CV60) ??
 
NCP BF takes an extended UNBIND and unextends it when necessary.
 
What needs clarification in DLUR architecture is when and how to convert
an extended UNBIND into an unextended UNBIND.
 
The proposed solution is to update the DLUR architecture reference
section on "LU-LU Session Deactivation" with the following:
 
    The UNBIND will be unextended if necessary, based on the extended
    BIND support indicators in the CV X'0C' in the +RSP(ACTLU) - this
    involves:
 
       * all UNBIND types except X'FE' - truncating the UNBIND RU to
         only the request code plus the UNBIND type;
 
       * UNBIND type X'FE' - truncating the UNBIND RU to only the
         request code, the UNBIND type, and the sense data.
 
    No reextending of the RSP(UNBIND) is required.